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ABSTRACT 

In  the  information  age  era,  there  never  has  been  a  better  time  to  reflect  upon  the  fact  that  information  in  itself 
is  something  that  has  to  be  engineered.  Since  command  and  control  is  a  cognitive  process  by  which  the 
commander  gains  situation  awareness  and  proceeds  to  deliberated  and  co-ordinated  action,  one  has  to  ask 
himself  how  raw  data  turns  into  actual  information,  and  eventually  knowledge  that  will  trigger  human 
understanding.  Furthermore,  the  question  arises  as  to  how  C4ISR  system  of  systems  can  support  this 
transformation  process.  Of  course,  this  is  no  magic.  Information  systems  do  the  only  thing  they  are  good  at: 
Working  on  large  amounts  of  data  at  incredible  speed.  This  is  where  the  human  fails.  However,  data  must  be 
aggregated  in  such  a  way  that  it  results  in  information  that  conveys  operational  meaning  to  the  commander. 
This  is  where  information  technologies  alone  fail,  miserably.  The  resulting  information  must  capture  the 
semantics  of  the  commander’s  domain  of  interest,  and  this  must  exist  prior  the  automated  data  transformation 
process.  The  exercise  of  capturing  the  semantics  of  a  certain  business  domain  (the  nouns,  verbs,  adjectives, 
etc.)  along  with  its  usage  guidance  (business  rules)  can  be  referred  to  as  information  engineering  or  ontology 
engineering.  Conducting  information  engineering  activities  comes  in  support  of  the  definition  of  ontologies. 
By  definition,  an  ontology  is  an  explicit  formal  specification  of  how  to  represent  the  objects,  concepts  and 
other  entities  that  are  assumed  to  exist  in  some  area  of  interest  and  the  relationships  that  hold  among  them. 
Broadly  speaking,  interoperability  can  be  achieved  for  systems  that  sit  on  top  of  a  single  common  ontology >,  or 
for  systems  that  sit  on  top  of  distinct  ontologies  provided  with  a  means  of  translation  between  the  crossing 
domains.  An  example  of  the  first  approach  is  the  Multilateral  Interoperability  Programme  ( MIP )  that  provides 
a  common  ontology  solution  consisting  of  the  Command  and  Control  Information  Exchange  Data  Model 
(C2IEDM),  supporting  land-focused  joint  military  operations.  In  the  next  2-year  phase,  its  focus  will  expand 
to  full-blown  joint  military  operations.  As  for  the  latter,  Defence  R&D  Canada  -  Valcartier  is  currently 
working  on  an  interoperability >  solution  between  the  Canadian  Land  Forces  Command  System  (LFCS)  and  the 
United  States  Global  Command  and  Control  System  (GCCS).  Both  systems  are  built  upon  distinct  ontologies 
and  rely  on  a  proper  translation  mechanism  to  achieve  operational  interoperability.  This  paper  describes  the 
information  engineering  process  (ontological  engineering)  that  must  take  place  in  order  to  successfully 
achieve  both  interoperability  solutions. 


Paper  presented  at  the  RTO  1ST  Symposium  on  “Coalition  C4ISR  Architectures  and  Information  Exchange  Capabilities  ”, 
held  in  The  Hague,  The  Netherlands,  27-28  September  2004,  and  published  in  RTO-MP-IST-042. 
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ORGANIZATION 


1.0  INTRODUCTION 

The  current  conduct  of  military  affairs  prescribes  the  formation  of  coalitions  to  achieve  missions.  The 
geopolitical  context  of  today  and  the  globalisation  of  communications,  notably,  force  us  to  think  of  the  world 
as  a  global  village.  The  well-known  “butterfly  effect”  example  borrowed  from  the  chaos  theory  is  ever  more 
important  as  the  butterfly  flap  is  so  much  more  effectively  propagated  throughout  the  world  than  it  was  years 
ago.  Because  of  that,  military  organisations  do  no  longer  operate  in  isolation.  They  must  operate  in  coalitions, 
politically-wise  and  operationally- wise.  Also,  since  information  operations  are  a  cornerstone  for  the  effective 
realisation  of  military  operations,  reliance  upon  information  systems  to  gather,  organise,  provide  decision  aids 
and  disseminate  information  is  increasing.  Therefore,  increased  collaboration  between  national  systems  to 
support  coalition  operations  is  necessary.  We  refer  to  this  kind  of  collaboration  as  systems  interoperability. 
This  collaboration  scheme,  to  be  comprehensive,  must  be  subdivided  into  several  levels,  one  of  which  is  the 
establishment  of  a  common  basis  for  the  semantic  concepts  that  will  be  shared  between  the  systems.  This 
paper  relates  the  author’s  experience  in  systems  interoperability  at  the  semantics  level,  following  two 
techniques  to  achieve  interoperability,  the  first  being  the  establishment  of  a  common  shared  ontology  that  will 
be  used  by  all  participants  who  want  to  participate  in  the  coalition.  This  is  what  the  Multilateral 
Interoperability  Programme  (MIP)  is  currently  defining  with  its  MIP  solution.  The  second  technique  is  to 
operate  a  translation  between  the  shared  semantic  concepts  that  are  comprised  in  two  distinct  ontologies.  In 
this  case,  a  translation  between  the  Command  and  Control  Information  Exchange  Data  Model  (C2IEDM)  [1] 
and  the  Over-The-Horizon  Targeting  GOLD  (OTH-T-GOLD)  [2]  will  be  illustrated.  In  either  case,  it  will  be 
shown  that  interoperability  can  be  achieved  only  if  semantic  elements  are  common  to  both  systems  domains. 


2.0  DEFINITION  OF  INTEROPERABIFITY 

The  term  interoperability  being  widely  in  use  and  defined  in  several  ways,  this  paper  will  focus  on  the  US 
Joint  Publication  1-02  definition,  where  interoperability  is: 


“The  ability  of  systems,  units,  or  forces  to  provide  sendees  to  and  accept  services  from 
other  systems,  units,  or  forces,  and  to  use  the  services  so  exchanged  to  enable  them  to 
operate  effectively  together.  ”  [3] 

The  Levels  of  Information  Systems  Interoperability  (LISI)  [4]  provides  a  5-level  hierarchy  for  interoperability 
focused  on  4  attributes.  The  PAID  attributes  (Procedures,  Applications,  Infrastructure  and  Data)  form  the 
orthogonal  aspects  vectors  that  qualify  systems  interoperability  while  the  5-level  hierarchy,  ranging  from 
isolated  to  enterprise,  qualify  the  degree  of  achieved  interoperability.  The  fact  that  one  of  the  four  attributes  is 
Data  shows  the  importance  that  semantics  play  in  the  interoperability  scheme. 

The  NATO  C3  Technical  Architecture  [5]  also  defines  a  hierarchy  of  interoperability  degrees,  ranging  from 
unstructured  data  exchange  to  seamless  sharing  of  information.  This  hierarchy  is  refined  into  sub-degrees 
representing  functional  derivatives  of  the  four  interoperability  degrees.  In  this  sense,  the  MIP  solution  aims  at 
achieving  interoperability  degree  2.h  (Structured  Data  Exchange/Data  Object  Exchange)  for  its  human- 
interpretable  information  exchange  mechanism  and  degree  4. a  (Seamless  Sharing  of  Information/Common 
Information  Exchange)  for  its  systems-interpretable  information  exchange  mechanism.  OTH-T-GOLD,  as  a 
message  text  format  (MTF)  allows  for  interoperability  degree  2.h. 
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It  would  seem  that  attaining  higher  levels  of  interoperability  (either  from  LISI’s  or  NC3TA’s  perspective)  is 
desirable.  In  fact,  lower  levels  may  very  well  address  the  operational  needs  for  systems  interoperability.  Since 
also  that  higher  levels  require  more  money  and  effort  to  achieve,  one  has  to  carefully  weigh  the  pros  and  cons 
of  adopting  the  interoperability  “nirvana”  while  in  fact  the  “right”  level  depends  on  the  operational  concept 
over-arching  the  need  for  interoperability.  The  operational  concept  is  the  actual  driving  force  for  defining  the 
level  of  interoperability  needed  between  systems.  This  principle  becomes  a  prime  factor  for  information 
engineering,  either  when  defining  a  shared  common  ontology  (e.g.  the  C2IEDM)  or  when  translating  between 
two  ontologies. 


3.0  ONTOLOGIES:  DEFINITION  AND  ROLE 

Ontologies  have  received  increasing  interest  in  computer  science  and  information  systems.  They  explicitly 
encode  a  shared  understanding  of  a  domain  that  can  be  communicated  between  people  and  application 
programs  [6],  According  to  Gruber  [7],  an  ontology  is  « an  explicit  specification  of  a  shared 
conceptualisation  ».  That  means  that  it  formally  specifies  the  entities  that  exist  in  some  area  of  knowledge  and 
relationships  that  hold  among  them.  It  is  shared  in  that  it  represents  consensual  knowledge  of  a  community  of 
agents  that  adhere  to  the  definitions. 

In  the  literature,  ontologies  range  from  controlled  vocabularies  to  highly  expressive  domain  models  [8]: 
integrated  data  dictionaries  designed  for  human  understanding,  taxonomies  organizing  concepts  of  a  domain 
into  inheritance  hierarchies,  structured  data  models  suitable  for  data  management,  and  finally  highly 
expressive  computational  ontologies.  Within  this  ontology  spectrum,  a  controlled  vocabulary  is  a  finite  set  of 
terms  with  unambiguous  definitions.  A  taxonomy  is  a  collection  of  controlled  vocabulary  terms  organized  into 
a  hierarchical  structure,  the  terms  being  linked  by  generalization-specialization  relations.  A  thesaurus  is  a 
networked  collection  of  controlled  vocabulary  terms,  where  the  relations  between  terms  in  thesaurus  hierarchy 
are  interpreted  as  narrower-broader  relations.  Conceptual  models  (e.g.  database  model)  are  also  part  of  the 
spectrum  but  usually  concern  a  restricted  domain  and  are  built  for  specific  applications.  Ontologies  add  more 
expressiveness  in  the  specification  of  relationships  between  concepts.  Formal  ontologies  use  a  representation 
language  to  specify  properties  and  constraints  of  concepts  that  can  be  exploited  for  automated  reasoning 
(inferencing). 

In  our  perspective,  an  ontology,  as  a  conceptualisation  of  a  domain,  explicitly  captures  the  semantics  of  the 
entities  in  that  domain.  It  comprises  the  definition  of  concepts,  their  properties,  attributes,  relations,  as  well  as 
constraints  and  axioms  that  constrain  the  meaning  of  the  concepts  (disambiguation).  It  formally  specifies  the 
meaning  of  the  concepts  in  order  to  make  domain  assumptions  explicit  and  prevent  errors  in  data 
inteipretation.  An  important  aspect  in  the  ontology  development  process  is  to  explicitly  establish  relationships 
that  exist  between  concepts.  De  facto  relationships  between  concepts  in  ontologies  include  relations  that  link  a 
concept  with  more  specific  concepts  (is-a/ 'subsume  relation)  and  relations  that  link  a  complex  object  to  its 
constituents  (part-of /contains  relation).  Any  variety  of  relations  that  exist  among  entities  should  be  specified, 
for  example  causal,  functional  dependencies,  or  temporal  relations. 

Due  to  their  fonnal,  expressive  and  shared  properties,  ontologies  constitute  domain  models  that  can  be  reused 
across  applications,  facilitating  knowledge  sharing  and  reuse.  Moreover,  ontologies  facilitate  semantic 
information  integration  and  interoperability  between  heterogeneous  sources  at  a  high  level  of  abstraction. 
They  can  also  be  exploited  to  index  and  access  semi-structured  information  sources.  They  facilitate 
information  retrieval  over  collections  of  heterogeneous  and  distributed  information  sources. 
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Finally,  some  critical  issues  to  be  considered  regarding  ontological  engineering  are  the  cost  of  developing  and 
maintaining  ontologies,  and  the  fact  that  ontologies  should  be  extensible  and  evolve  over  time. 

In  reaching  for  systems  interoperability,  two  solutions  are  possible  at  the  semantics  level: 

•  A  single  shared  common  set  of  semantic  elements  is  defined,  so  that  disparate  systems  that  are  built 
upon  it  achieve  semantics  interoperability  at  once. 

•  A  translation  mechanism  between  two  (or  more)  ontologies  is  defined  so  that  minimal  semantics 
interoperability  is  achieved. 


System  A  System  B 


System  A  and  B  share  no  semantics  elements.  I 

Therefore  interoperability  is  NOT  possible 


Semantics  Elements 


Shared  semantics  elements  capture 
equivalent  concepts  in  both  ontologies 
although  they  may  be  expressed 
differently.  Interoperability  is  possible. 


Figure  1:  Semantics-level  Interoperability 
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4.0  SEMANTIC-LEVEL  INTEROPERABILITY 

One  thing  must  be  said  about  interoperability  at  the  semantics  level  that  it  is  not  always  possible.  Figure  1 
shows  an  illustration  of  this  as  two  systems  can  only  interoperate  if  they  share  some  of  the  semantic  elements 
their  distinct  ontologies  capture.  The  shared  elements  may  be  expressed  differently  but  they  nonetheless  have 
to  exist  in  both  ontologies.  Consequently,  the  need  for  operational  interoperability  (e.g.  Navy  systems 
interoperating  with  Land  force  systems)  requires  that  the  semantics  of  the  information  to  be  exchanged  exist 
in  both  domains.  Whether  the  means  to  express  the  semantics  are  the  same  or  different  does  not  change  the 
need  for  the  concept  to  exist  in  both  worlds.  The  military  realm  offers  a  strong  context  around  which  the 
semantics  of  different  domains  (air,  navy,  land,  joint)  often  overlap.  The  semantics  overlap  is  the  actual  region 
where  one  can  seize  the  opportunity  to  make  two  systems  talk  to  each  other  at  the  same  semantic  level. 

The  question  arises  then  as  to  what  degree  of  semantic  overlapping  is  required  to  achieve  interoperability 
between  two  systems.  The  answer  lies  in  the  specification  of  the  operational  need  for  interoperability.  Military 
interoperability  occurs  when  different  services  (air,  navy,  land,  joint)  in  a  combined  fashion  and  also  in  the 
international  context  (coalition).  The  reason  for  this  is  that  each  of  these  entities  develops  C2  systems  that  suit 
their  specific  needs.  Conducting  combined  and  coalition  operations  gives  a  strong  context  about  the 
information  that  must  be  exchange  between  partners.  This  in  turn  conditions  the  semantic  elements  that  must 
exist  in  each  stakeholders’  ontologies.  Therefore,  the  operational  context  will  always  be  the  driving  force  and 
rationale  for  systems  interoperability. 


5.0  THE  MULTILATERAL  INTEROPERABILITY  PROGRAMME 

The  goal  of  the  MIP  is: 

“to  achieve  international  interoperability  of  Command  and  Control  Information 
Systems  (C2IS)  at  all  levels  from  corps  to  the  lowest  appropriate  level,  in  order  to 
support  multinational,  combined  and  joint  operations  and  the  advancement  of 
digitisation  in  the  international  arena,  including  NATO.  ’’  [9] 

For  the  past  years,  the  MIP  community  has  been  working  on  the  establishment  of  its  MIP  solution  that  is  two¬ 
fold: 


•  Capturing  the  semantics  of  the  coalition  land  force  operations  and  the  relationships  between  the 
semantic  elements  of  the  battlefield.  This  resulted  in  the  creation  of  the  C2IEDM  and  derived 
artefacts,  leading  to  the  complete  expression  of  the  coalition  land  force  ontology. 

•  An  information  exchange  mechanism  (IEM)  that  would  enable  the  information  flow  between  systems. 

To  achieve  this,  the  MIP  always  counted  on  a  strong  definition  of  the  operational  concepts  for  land  operations 
(Figure  2).  The  MIP  Operational  Working  Group  (OWG)  gathers  Subject  Matter  Experts  (SMEs)  and  define 
the  Information  Exchange  Requirements  (IERs)  needed  to  conduct  land  operations.  These  are  then 
decomposed  into  Information  Content  Elements  (ICEs),  like  molecules  broken  into  atoms  of  information.  The 
ICEs  are  then  mapped  against  the  C2IEDM.  This  process  in  necessary  since  it  prevents  the  mapping  of 
information  elements  that  are  already  in  the  data  model.  The  C2IEDM  is  then  enriched  with  business  rules 
that  prevent  a  wrongful  utilisation  of  the  semantic  elements.  The  data  model  in  itself  cannot  express  all  the 
constraints  that  must  be  met  to  ensure  semantic  integrity,  or  to  express  all  possible  relationship  between 
semantic  concepts.  Therefore,  the  data  model  by  itself  does  not  constitute  an  ontology.  It  must  be  augmented 
with  documentation  that  describes  all  possible  and  forbidden  relationships  that  can  occur  between  semantic 
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ORGANIZATION 


elements.  The  C2IEDM  is  therefore  always  presented  with  its  main  documentation  and  annexes  [1]. 
Generally,  the  MIP  data  modellers  try  to  render  every  possible  aspect  of  the  C2IEDM  as  explicit  as  possible 
so  that  a  systems  developer  can  use  it  as  a  comprehensive  ontology.  Whether  it  is  explicit  enough  to  be 
considered  as  a  pure  ontology  is  not  clear  in  the  author’s  mind. 

What  is  remarkable  though  about  the  MIP  is  that  they  are  “living”  the  problem  of  interoperability.  Reporting 
all  aspects  of  this  is  clearly  out  of  this  paper’s  scope,  but  let  it  be  said  that  fundamental  problems  arising  from 
the  set  up  of  an  interoperability  solution  constitute  a  tangible  and  observable  artefact  for  an  outsider.  This, 
more  than  anything,  makes  the  MIP  a  very  interesting  experience  for  researchers. 


> 


Ontology? 


Figure  2:  Information  Exchange  Requirements  Process 


6.0  MAPPING  THE  OTH-T-GOLD  MESSAGE  TEXT  FORMAT  TO  THE  C2IEDM 

While  it  is  desirable  to  have  every  systems  sit  on  top  of  the  same  ontology,  and  also  to  have  every  military 
stakeholders  to  agree  upon  the  same  set  of  semantic  concepts,  it  is  not  always  economically  feasible  to 
systems  that  are  currently  fielded.  Therefore,  the  fallback  solution  is  to  try  to  build  a  piece  of  code  that  will 
translate  semantic  concepts  from  one  ontology  to  another.  Defence  R&D  Canada  Valcartier  worked  an 
interoperability  solution  between  the  US  Global  Command  and  Control  System  (GCCS)  and  the  Canadian 
Land  Forces  Command  and  Control  Information  System  (LFC2IS).  GCCS  uses  OTH-T-GOLD  as  a  means  of 
interoperability  between  its  own  workstations  and  LFC2IS  sits  directly  on  top  of  the  MIP  solution  (C2IEDM 
and  IEM). 

6.1  Operational  Concept 

It  was  mentioned  that  the  first  step  was  to  identify  the  operational  concept.  Indeed,  recognizing  the  operational 
concept  as  the  driving  force  that  prompts  interoperability  is  the  key  and  allows  the  definition  of  the 
information  exchange  requirements.  In  this  exercise,  the  idea  was  for  the  land  forces  to  be  able  to  inform  the 
navy  about  its  own  land  units  information  and  to  get  in  return  information  about  the  navy  ships  information 
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(tracks).  The  operational  concept  is  to  gain  shared  awareness  about  mutual  owned  information  (land  vs  navy) 
so  that  missions  would  be  conducted  with  a  degree  of  synchrony  that  was  before  only  possible  through  human 
intervention. 

6.2  Information  Exchange  Requirements 

An  analysis  of  both  OTH-T-GOLD  and  C2IEDM  revealed  a  number  of  sets,  attributes,  fields  and  values  that 
would  convey  the  information  needed  to  support  the  operational  concept.  For  example,  the  XCTC  message  in 
OTH-T-GOLD  would  be  the  main  vehicle  for  navy  information  to  the  land  component  while  several  attributes 
of  the  C2IEDM  would  fill  a  JUNIT  and  JPOS  so  that  land  information  would  populate  the  navy  system.  It  is  a 
very  long  and  fastidious  exercise,  but  a  necessary  one  to  align  semantic  elements  of  both  ontologies. 

6.3  Semantic  Loss  and  Bi-directional  Information  Exchange 

We  know  that  for  interoperability  to  be  possible,  both  ontologies  must  comprise  some  semantic  elements  that 
they  must  share.  However,  information  elements  that  are  used  to  express  these  semantic  elements  may  differ, 
and  sometimes  they  differ  significantly.  For  example,  both  OTH-T-GOLD  and  C2IEDM  are  capable  of 
expressing  ship  types.  However,  the  need  for  details  about  ship  types  differs  from  the  land  component  to  the 
navy  component.  A  “Mig  29”  in  OTH-T-GOLD  corresponds  to  a  “fixed  wing  fighter”  in  the  C2IEDM.  It 
becomes  self-evident  then  that,  while  the  operational  concept  is  supported  if  these  information  elements  are 
mapped  together,  there  is  no  way  they  can  be  exchanged  back  and  forth  between  the  systems.  It  is  also  self- 
evident  that  a  C2IEDM  “fixed  wind  fighter”  cannot  be  mapped  to  a  “Mig  29”  in  the  OTH-T-GOLD  because 
there  is  not  enough  details  to  determine  this  fact.  Therefore,  the  mapping  must  occur  between  information 
elements  that  are  detailed  enough  to  “nourish”  the  generic  information  elements,  provided  that  the  semantics 
necessary  to  support  the  operational  concept  is  still  conveyed  between  the  systems.  We  can  define  this  as  an 
“acceptable  semantics  loss”.  This  is  not  that  different  from  jpg  image,  where  loss  of  information  is  accepted  to 
result  in  smaller  files  while  the  image  still  conveys  the  same  information  to  the  eye.  This  also  demonstrates 
that  most  of  the  time,  information  elements  pushed  to  the  other  system  and  pulled  back  will  not  look  the  same 
as  it  was.  In  other  words,  bi-directional  information  exchange  is  often  impossible  to  realize.  Does  this  mean 
that  bi-directional  interoperability  is  impossible?  No!  The  nature  of  information  exchanged  between  systems 
can  be  asymmetric.  In  fact,  this  asymmetry  is  desirable  as  it  prevents  this  kind  of  problem.  Of  course,  this 
again  should  not  contravene  with  the  operational  concept.  In  our  example,  it  made  sense  since  land 
information  belongs  to  the  land  system  while  navy  information  belongs  to  the  navy  system.  It  was  never  a 
question  whether  land  information  should  come  from  the  navy  system  and  vice-versa.  In  other  words,  one- 
directional  information  exchange  supported  bi-directional  interoperability  for  this  operational  concept.  One 
who  attempts  this  kind  of  interoperability  exercise  should  bear  in  mind  that  semantic  loss  almost  always  arises 
in  the  process,  so  it  is  better  to  clarify  which  system  bears  the  “master”  information.  Otherwise,  it  may  lead  to 
major  troubles. 


7.0  CONCLUSION 

Achieving  systems  interoperability  requires  that  there  is  sufficient  semantics  overlap  between  systems’ 
respective  ontologies.  This  paper  described  the  steps  necessary  to  realize  semantics  interoperability  either  by 
adopting  one  and  only  one  ontology  or  by  designing  a  means  to  migrate  from  one  ontology  to  another.  These 
steps  were  labelled  as  information  engineering.  Information  engineering  aspects,  characteristics  and 
particularities  were  illustrated  for  both  approaches.  In  either  case,  reaching  for  systems  interoperability  makes 
sense  only  if  it  supports  an  operational  concept  for  the  exchange  of  information.  Keeping  this  in  mind,  the 
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development  of  a  single  shared  ontology  will  stabilize  as  soon  as  the  operational  concept  is  supported.  The 
same  applies  to  the  harmonization  of  two  distinct  ontologies:  a  partial  mapping  constitutes  a  success  if  the 
over-arching  operational  concept’s  goal  is  met. 
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Goal  of  the  Presentation 


To  propose  a  reflection  on  the  conduct  of  activities 
leading  to  the  construction  of  an  ontological  basis, 
a  necessary  prerequisite  for  systems-to-systems 
interoperability  realisation. 


This  conduct  of  activities  will  be  referred  to  as 
information  engineering  within  the  context  of  this 
presentation. 
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nsj  Goal  of  the  Presentation 


•  Illustrate  the  Multilateral  Interoperability 
Programme  (MIP)  Data  Modelling  Working 
Group  (DMWG)  work  process:  The  construction 
of  the  C2  Information  Exchange  Data  Model 
(C 2 IE  DM). 


->  Single  Shared  Ontology  Construction 

Illustrate  a  semantic  mapping  between  the 
C2IEDM  and  the  OTH-T-GOLD  specification. 

->  Distinct  Ontologies  Interface  Construction 


Defence  R&D  Canada  -  Valcartier  •  R  &  D  pour  la  defense  Canada  -  Valcartier 


Working  Definition  of  “Interoperability” 


«  The  ability  of  systems,  units,  or  forces  to  provide 
services  to  and  accept  services  from  other  systems, 
units,  or  forces,  and  to  use  the  services  so  exchanged 
to  enable  them  to  operate  effectively  together.  » 

Joint  Pub  1  -02 


'A 
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r\,J  Working  Definition  of  “Interoperability” 


Operational  Context 


The  operational  context  is  the  driving  force 
for  systems  interoperability. 
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Working  Definition  of  “Ontology” 


An  ontology,  as  a  conceptualisation  of  a  domain, 
explicitly  captures  the  semantics  of  the  entities  in 
that  domain.  It  comprises  the  definition  of  concepts, 
their  properties,  attributes,  relations,  as  well  as 
constraints  and  axioms  that  constrain  the  meaning 
of  the  concepts. 
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ruy  Semantic-level  Interoperability 


System  A 


Ontology  O 


System  B 


System  C 
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Joint  Interoperability  with  a  Single  Shared 

Ontology  (C2IEDM) 
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Information  Engineering  Process 


V 


no 


Examine  the  operational  environment  from  an 
information  engineering  perspective 

Create  an  operational  working  group  that  will 
comprise  experts  from  each  domain 

Gather  Information  Requirements  (IRs)  and 
Information  Exchange  Requirements  (IERs) 

Break  IRs  and  IERs  into  Information  Content 
Elements  (ICEs) 

Ensure  a  shared  understanding  of  the  ICEs 


Establish  the  C2IEDM  data  model  against  ICEs 
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V 


RD 


Figure  1.  IER  Evaluation  Process 
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IERs  Sources 


V 


RD 


•  135  STANAGS 
inc.  5620  and  5621 

•  AD  80-50 

•  AAFCE  80-50 

•  CENTAG  SOP 

• NORTHAG  SOP 

•  ATP-35 

•  ATP-40 

•  ATP-45 

•  ADatP  -  3 

•  AIntP  -  3 

•  APP-9 

•  APP-6  &  6A 

•  SD  &  IC 


•  SOP’s  from  Nations 


National 


US  Message  Text  Formats 
Message  Formats 
Message  Standards 
National  Doctrine 


Functional 

Models 


MCCRT 

AIMS/IME 

BICES 

ADAMS 

ACCS 

DIGEST 

MIDB 
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ruy  Requirements  for  the  C2IEDM 

•  Article  V  (or  MIP)  IERs. 

•  Crisis  Response  Operations  (CROs)  IERs. 

•  Combined  Joint  Task  Force  (CJTF)  IERs. 
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ruy  Minimum  Exchange  Requirements  (examples) 


First  Hostile  Act 


Intelligence  Report 
Intelligence  Request 
Intelligence  Summary 
Land  Intelligence  Report 
Enemy  Situation  Report 
Presence 

Own  Land  Force  Situation 
Report 


Rule  of  Engagement 
Request 


Rule  of  Engagement 
Implementation 

Commander’s  Assessment 

NBC  Chemical  Downwind 
Report 

NBC  Effective  Downwind 
Report 

NBC  1  and  3 

Operational  Plan/Order 

Fragmentary  Order 

Logistic  Situation  Report 
Land  Forces 

Logistic  Assessrep  Report 
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CROs  Exchange  Requirements 


Arrest  Report 
Border  Crossing 
Camps 

Civil  Military  Operations 
Confiscated  Equipment 
EOD  Incident 
Holdings  Parties 
Host  Nation  Support 
Incident  Report 
Mass  Graves 
Meteorology 


•  Personnel  Identification 

•  PSYOPS 

•  Displaced  Persons 

•  Refugees 
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R*y  C  JTF  Exchange  Requirements 


Air  and  Sea  Picture 
Domain 


Control  Measures 
Fire  Support 
Ground  Picture 
Unit  and  Facility 

Logistics  Domain 

•  Force  Maintenance 

•  Force  Movement 


Joint  Intelligence 
Domain 

Air/Marine  Intelligence 
Human  Intelligence 
Joint  Electronic  Warfare 
Collection  Management 
Targeting 


*  Medical  Support 

*  Logistic  and  Combat 
Service  Support 
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rUY  Linking  ICEs  with  IERs 


IER 


l 


has  an  element 


Indicated  via 


IER-ICE-ASSOCIATION 


lER-short-name-id  (FK) 

ICE-id  (FK) 
lER-ICE-ASSOCIATION-indei 


lER-short-name-id 


lER-name-text 

lER-purpose-text 

lER-priority-code 

lER-staff-code 

lER-source-code 

lER-reference-text 

lER-priority-ranking 


SUBECT-AREA 


SUBJECT-AREA-id 

is  reference  for 

SUBJECT-AREA-text 

J 

SUBJECT-AREA-ICE-ASSOCIATION 


ICE-id  (FK) 

SUBJECT-AREA-id  (FK) 


SUBJECT-AREA-ICE-ASSOCIATION-analyst-te>:t 


is  contained  in  an  IER 


OPS-COMMENTS 


as  indicated  by 


ICE-id  (FK) 

OPS-COMMENTS-index 


OPS-COMMENTS-evaluator-code 
OPS-COMMENTS-date 
OPS-COMMENTS-status-code 
OPS-COMMENTS-necessity-code 
OPS-COMMENTS-text 


ICE 

is  assessed  as  provided  ir  ICE-id 


is  assigned  a  topical 


classification  through 


I 


ICE-ASSOCIATION 


ICE-MAPPING 


ICE-id  (FK) 
ICE-MAPPING-index 

ICE-MAPPING-evaluator-code_ 
ICE-MAPPING-date-text 
ICE-MAPPING-status-code 
ICE-MAPPING-category-code 
ICE-MAPPING-evaluation-text 


ICE-CONDITION 


is  evaluated 
against  LC2  in' 


ICE-id  (FK! 
ICE-CONDITION-inde)*- 


ICE-CONDITION-text 


may  have  a  qualifying 


ICE-name-text 
ICE-definition-text 
ICE-precedence-code 
I  CE-ana  ly  st-com  ment-tex 


Primary-ICE-id  (FK) 
Secondary-ICE-id  (FK) 


J 


|  may  serve  as  primary  through 
may  be  deemed  secondary  through 


may  have  an  associated  mav  have 

•  i — - 

ICE-DOMAIN _ 

ICE-id  (FK) 

ICE-DOMAIN-index _ 

ICE-DOMAIN-logical-value-text 
ICE-DOMAIN-value-definition-texjt 
ICE-DOMAIN-physical-value-text 


-ICE-DOMAIN-SUBTYPE 

_ -  - 


ICE-id  (FK) 

ICE-DOMAIN-index  (FK) 
ICE-DOMAIN-SUBTYPE-index 

ICE-DOMAIN-SUBTYPE-logical-value 
ICE-DOMAIN-SUBTYPE-value-definitioh 
ICE-DOMAIN-SUBTYPE-physical-value 


ivuti/  V/Miiaua  ' 


t  aivai  uti 


jlv  ix,  JL/ 


r\j  ui  la  uvituDV  v^anaua  - 


▼  au-ai 


tier 


Classifying  ICEs  into  Subject  Areas 


Organisation 

Location 

Rules  of  Engagement 

Materiel 

Control  Features 

Holdings 

Status  of  Items 

NBC  defensive 

Activity 


•  Capability 

•  Objects 

•  Candidate  Target 

•  Facility/Installation 

•  Person 

•  Geographic  Feature 

•  Medical 

•  Weather 

•  Communications 
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Pros  and  Cons  of  a  Single  Shared  Ontology 

(C2IEDM  /  MIP  context) 


Pros 


Cons 


•  Only  1  interface  to  write  to 
achieve  interoperability 
with  the  community. 


•  You  have  to  spend  energy 
to  have  everybody  agreeing 
upon  a  concept. 


•  100%  shared  understanding. 

•  Increased  maintainibility. 


Legacy  systems  can  hardly 
adapt. 
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Joint  Interoperability  using  Different 

Ontologies 
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Semantic  translation  mechanism 


•  Conduct  a  Semantic  Translation  Analysis 


•  Identify  the  Systems  Entry  Points 


•  Develop  the  grinder  that  will  speak  both  languages 


Examine  the  operational  context  under  which 
the  bilateral  information  exchange  will  take 
place 

Identify  Information  Requirements  (IRs)  and 
Information  Exchange  Requirements  (IERs) 

Break  them  into  ICEs  and  verify  if  their 
semantics  are  captured  in  both  ontologies 

Make  the  connection  between  the  data  elements 
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ruy  Practical  Example  (conducted  at  DRDC-V) 

•  LC2IEDM  OTH-T-GOLD  (GCCS) 

-  Operational  Context:  Support  Land/Navy  Joint 
Operations 

-  IERs:  Pushing  Land  Units  Positions  and  Pulling 
Maritime  Tracks 

•  No  bi-directional  pulling/pushing 
(asymmetrical  exchange) 
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ICEs  Semantics  Existence  in  both  Models 


OTH-T  GOLD  CTC  Set  Fields  and  LC2IEDM/ODB  Attributes  Correspondence 

POS/JPOS  Field 

LC2IEDM  5.3 

ODB 

Comment 

1-  DATE -TIME  GROUP 

reporting-data-absolute-timing-effective-date 

reporting-data-absolute-timing-effective-date 

2-  MONTH 

3-  LATITUDE  OF  CENTER 

absolute-point-latitude-coordinate 

absolute-point-latitude-coordinate 

4-  LONGITUDE  OF  CENTER 

absolute-point-longitude-coordinate 

absolute-point-longitude-coordinate 

5-  SENSOR  CODE 

reporting-data-source-type-code 

reporting-data-source-type-code 

Proposition  to  skip  this  field  because  there 
is  too  much  semantic  disparity  between 
OTH-T  GOLD  and  the  LC2IEDM. 

7-  LENGTH  OF  SEMI-MAJOR  AXIS 

object-item-location-accuracy-quantity 

organisation-point-accuracy-quantity 

9-  COURSE 

object-item-location-bearing-angle 

organisation-point-bearing-angle 

10- SPEED 

object-item-location-speed-rate 

organisation-point-speed-rate 
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Mapping  Data  Elements 


OTH-T  GOLD  Rev  B  and  C  Entry  List  59 

LC2IEDM  5.3 

Country 

Code 

Country 

Code 

Exercise  NATO  Force 

OT 

Not  otherwise  specified 

NOS 

Exercise  Neutral  Country 

zc 

Not  otherwise  specified 

NOS 

Exercise  Neutral  Force 

zz 

Not  otherwise  specified 

NOS 

German  Democratic  Republic 

GC 

Not  otherwise  specified 

NOS 

Germany 

GM 

Germany,  Federal  Republic  of 

GE 

Germany,  Berlin 

BZ 

Not  otherwise  specified 

NOS 

Germany,  Federal  Republic  of 

GE 

Germany,  Federal  Republic  of 

GE 

Ghana 

GH 

Ghana 

GH 

Gibraltar 

Gl 

Gibraltar 

Gl 
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Pros  and  Cons  of  Designing  a  Meat  Grinder 
between  2  Ontologies 


Pros 


Cons 


•  Low-cost  solution 

•  Usually  easier  to 
implement 


Information  Analysis  is 
usually  simpler 

Offer  a  possible 
interoperability  solution  for 
legacy  systems 


Semantics  disparities 
between  ontologies  (almost 
always) 

Symmetrical  exchange  is 
almost  always  a  no-no 
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Lessons  Learned  and  Conclusion 


•  Information  engineering 


-  Operational  context  (scope) 

-  Methodology 

•  Ontology  alignment 


-  Ontology  translations  always  suffer  semantic 
loss 

-  Acceptable  if  the  operational  context  is 
supported 

Ontological  engineering  (building,  alignment)  is 
always  complex  and  time-consuming 


Defence  R&D  Canada  -  Valcartier  •  R  &  D  pour  la  defense  Canada  -  Valcartier 


Questions??? 


DEFENCE 

Questions??? 


Questions??? 


Questions??? 


